Skip to main content

第 11 章：Git 分布式工作流程

你現在擁有了一個遠程 Git 版本庫，能為所有開發者共享代碼提供服務，在一個本地工作流程下，你也已經熟悉了基本 Git 命令。學習如何利用 Git 提供的一些分布式工作流程

分布式工作流程​

與傳統的集中式版本控制系統（CVCS）相反，Git 的分布式特性使得開發者間的協作變得更加靈活多樣。 在集中式系統中，每個開發者就像是連接在集線器上的節點，彼此的工作方式大體相像。 而在 Git 中，每個開發者同時扮演著節點和集線器的角色——也就是說， 每個開發者既可以將自己的代碼貢獻到其他的倉庫中，同時也能維護自己的公開倉庫， 讓其他人可以在其基礎上工作並貢獻代碼。 由此，Git 的分布式協作可以為你的項目和團隊衍生出種種不同的工作流程， 接下來的章節會介紹幾種利用了 Git 的這種靈活性的常見應用方式。 我們將討論每種方式的優點以及可能的缺點；你可以選擇使用其中的某一種，或者將它們的特性混合搭配使用。

集中式工作流​

集中式系統中通常使用的是單點協作模型——集中式工作流。 一個中心集線器，或者說 倉庫，可以接受代碼，所有人將自己的工作與之同步。 若幹個開發者則作為節點，即中心倉庫的消費者與中心倉庫同步。

01101.png)

這意味著如果兩個開發者從中心倉庫克隆代碼下來，同時作了一些修改，那麽只有第一個開發者可以順利地把數據推送回共享服務器。 第二個開發者在推送修改之前，必須先將第一個人的工作合並進來，這樣才不會覆蓋第一個人的修改。 這和 Subversion （或任何 CVCS）中的概念一樣，而且這個模式也可以很好地運用到 Git 中。

如果在公司或者團隊中，你已經習慣了使用這種集中式工作流程，完全可以繼續采用這種簡單的模式。 只需要搭建好一個中心倉庫，並給開發團隊中的每個人推送數據的權限，就可以開展工作了。Git 不會讓用戶覆蓋彼此的修改。

例如 John 和 Jessica 同時開始工作。 John 完成了他的修改並推送到服務器。 接著 Jessica 嘗試提交她自己的修改，卻遭到服務器拒絕。 她被告知她的修改正通過非快進式（non-fast-forward）的方式推送，只有將數據抓取下來並且合並後方能推送。 這種模式的工作流程的使用非常廣泛，因為大多數人對其很熟悉也很習慣。

當然這並不局限於小團隊。 利用 Git 的分支模型，通過同時在多個分支上工作的方式，即使是上百人的開發團隊也可以很好地在單個項目上協作。

集成管理者工作流​

Git 允許多個遠程倉庫存在，使得這樣一種工作流成為可能：每個開發者擁有自己倉庫的寫權限和其他所有人倉庫的讀權限。 這種情形下通常會有個代表“官方”項目的權威的倉庫。 要為這個項目做貢獻，你需要從該項目克隆出一個自己的公開倉庫，然後將自己的修改推送上去。 接著你可以請求官方倉庫的維護者拉取更新合並到主項目。 維護者可以將你的倉庫作為遠程倉庫添加進來，在本地測試你的變更，將其合並入他們的分支並推送回官方倉庫。 這一流程的工作方式如下所示（見 集成管理者工作流。）：

  • 項目維護者推送到主倉庫。
  • 貢獻者克隆此倉庫，做出修改。
  • 貢獻者將數據推送到自己的公開倉庫。
  • 貢獻者給維護者發送郵件，請求拉取自己的更新。
  • 維護者在自己本地的倉庫中，將貢獻者的倉庫加為遠程倉庫並合並修改。
  • 維護者將合並後的修改推送到主倉庫。
  • 集成管理者工作流。

011102.png)

這是 GitHub 和 GitLab 等集線器式（hub-based）工具最常用的工作流程。人們可以容易地將某個項目派生成為自己的公開倉庫，向這個倉庫推送自己的修改，並為每個人所見。 這麽做最主要的優點之一是你可以持續地工作，而主倉庫的維護者可以隨時拉取你的修改。 貢獻者不必等待維護者處理完提交的更新——每一方都可以按照自己的節奏工作。

主管與副主管工作流​

這其實是多倉庫工作流程的變種。 一般擁有數百位協作開發者的超大型項目才會用到這樣的工作方式，例如著名的 Linux 內核項目。 被稱為 副主管（lieutenant） 的各個集成管理者分別負責集成項目中的特定部分。 所有這些副主管頭上還有一位稱為 主管（dictator） 的總集成管理者負責統籌。 主管維護的倉庫作為參考倉庫，為所有協作者提供他們需要拉取的項目代碼。 整個流程看起來是這樣的（見 主管與副主管工作流。 ）：

普通開發者在自己的主題分支上工作，並根據 master 分支進行變基。 這里是主管推送的參考倉庫的 master 分支。

副主管將普通開發者的主題分支合並到自己的 master 分支中。

主管將所有副主管的 master 分支並入自己的 master 分支中。

最後，主管將集成後的 master 分支推送到參考倉庫中，以便所有其他開發者以此為基礎進行變基。

主管與副主管工作流。

011103.png)

這種工作流程並不常用，只有當項目極為龐雜，或者需要多級別管理時，才會體現出優勢。 利用這種方式，項目總負責人（即主管）可以把大量分散的集成工作委托給不同的小組負責人分別處理，然後在不同時刻將大塊的代碼子集統籌起來，用於之後的整合。

工作流程總結​

上面介紹了在 Git 等分布式系統中經常使用的工作流程，但是在實際的開發中，你會遇到許多可能適合你的特定工作流程的變種。 現在你應該已經清楚哪種工作流程組合可能比較適合你了，我們會給出一些如何扮演不同工作流程中主要角色的更具體的例子。 下一節我們將會學習為項目做貢獻的一些常用模式。